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SUMMARY 

CRT-b— ad text editor* offer a better user interface than most tele typ e baaed text editors 
hot are m ere complex and lees portable. Building a screen editor aa a front end to a line 
editor exploit* existing code, yields a more compact, portable result, and permits one 
to edit another’s flies. TMs paper describes such an editor. 

Kir wood* Text editor CRT Front end Portable Ratfor 

INTRODUCTION 

Different text editors present different user interfaces but perform similar functions. Each 
prints, inserts, deletes and changes characters, moves a cursor about, searches for keys and 
performs file i/o. However, there are important differences in how different editors present 
text and locate the text to be changed. 1 

Line editors, 1 designed for slow hard-copy terminals, present text a line at a time and 
only on explicit request Screen editors,* designed for fast CRT terminals, display text a 
screen at a time and update it after each editing operation so the user always views the 
current version of the text. This reduces the chance of error and spares the user the overhead 
of explicit requests to view lines. 

The user of a line editor indicates target text with a line number or context. The editor 
may have a special name for the current line and support relative positioning with line 
number arithmetic, but the user must still name the target line. This often forces the user 
to follow a printed listing. The user of a screen editor specifies target text by pointing a 
cursor at it. Typed characters replace the indicated text immediately, and special characters 
delete or insert text immediately. Since the result is displayed immediately, editing errors 
are easily spotted and corrected. 

Since they must do at least as much as a line editor, most screen editors consume more 
resources than line editors: more memory, more processor time, more development time. 
They stack a complex, terminal-specific screen handler atop an already file system-specific 
editor. The result is large and not easily transported. It is no wonder that screen editors 
are so rare even though users find them so useful. The rest of this paper illustrates tech- 
niques that avoid these problems and yield a compact, portable screen editor. 

BUILDING ON A LINE EDITOR 

Since screen and line editors perform similar functions, a screen editor can be built as a 
front end to a line editor. A front-end screen editor lets an existing line editor do the bulk 
of the editing and occupies itself with managing the screen and decoding commands. It 
translates screen editor commands into line editor commands, sends them to the underlying 
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line editor and displays the response at the appropriate screen position (Figure 1). Several 
advantages recommend this approach. 
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Figure 1. A tcreen editor front end to a line editor 


B uilding on a line editor saves development time. A front-end screen editor need only 
decode commands and manage the screen. Existing line editor code performs the actual 
editing. The front end exploits an existing file system interface and so avoids many calls 
on an often-irritating operating system. It communicates •with the file system in the line 
editor’s command language using simple, well-documented, printable stringB. 

Building on a line editor improves portability. Few conventional, stand-alone screen 
editors are portable. This is easy to understand: they are, like other programs, somewhat 
machine-specific, but, unlike most other programs, they are also terminal-specific. A 
front-end screen editor is no less terminal-specific, though isolating the terminal handler 
in the compact front end may ease re-implementation. However, once this is transported, 
the complete screen editor may be moved by moving the underlying line editor a straight- 
forward task with the right editor* — or by exploiting a strategy made possible by the use of 
a front end. Most interactive systems support a line editor. Different systems offer different 
syntax though functions. So moving a front-end screen editor between machines 

may be accomplished by translating its twenty-odd line editor requests to the syntax of the 
line editor on the new machine; moving a conventional, stand-alone screen editor requires 
a new, non-portable operating system interface and, hence, experience with its file system. 
A front end may compensate for significant defects in the underlying line editor. For 
example, a screen editor’s intraline editing facility (replacing overstruck characters) is 
easily built even if the underlying line editor has no such capability. A good screen editor 
is easily built on a simple line editor. However, some disparities between line and screen 
editor may be too great. For example, when scanning for a key, one line editor may terminate 
when it exhausts the file while another might wrap around and continue the search from the 
beginning of the file. Here, portability— that is, rapid re-implementation in a new environ- 
ment- suffers unless the screen editor’s search commands reflect those of the underlying 

line editor. A front-end screen editor should improve its line editor, not rewrite it. 

Building on a line editor does, however, require that the front end and underlying line 
editor communicate. If interprocess communication is feasible, a front-end screen editor 
pro ce ss may so communicate its commands to, and receive its results from, another line 
editor process. If a single-process version is required and if the line editor source code is 
available, the line editor may usually be transformed into a subroutine called by the front 
end. The u n a vailab ility of source code disqualifies many line editors. Luckily, portable 
line editors— with source code— are freely available* 


AN IMPLEMENTATION 

The screen editor s was developed on a PDP10 as a front end to Kernighan and Plauger’s 
portable line editor edit.* It now runs on a PDP11 as a front end to edit or to the ed text 
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formatting, while a PDP10 supports more language processors; when preparing documents 
on the PDP11, a programmer may need to check the program— run, and hence stored, on 
the PDP10 — being documented. 

Fortunately, x and its offspring edit process need not run on the same machine. The 
PDP10 and PDP11 are linked with low-speed communications lines— the same 1200 baud 
hard-wired lines and 300 baud phone lines used to interface terminals to either machine— 
and so appear to one another as terminals. When asked to edit a remote file (flagged by a 
special name), the PDP11 s no longer creates a local edit process to accept and answer its 
commands, but instead may use such a communication line to log onto the PDP10 and 
create an edit process there. Looking like a PDP10 terminal running edit, s may send edit 
requests on, and receive edit responses over, this line. It no longer matters that the PDP10 
opera ting system discourages multiprocess jobs: s on the PDP11 appears to the PDP10 
as a terminal running edit — and only edit. 

Some care must be taken in this; for example, escape characters from the remote hie 
may be given special interpretations when they are received from a ‘terminal’. However, 
once such details are overcome, the result is a contrivance not much slower than running x 
from the PDP10: since most of the date passing between x and edit is intended for the 
screen, it has to pass over low-speed lines whether it goes straight to a PDP10 terminal or 
via the PDP11 to a PDP11 terminal. Of course, this feature of x is not portable, since it 
relies on special file names, a particular hardware configuration, and the uniform mechanism 
UNIX provides for terminal i/o and interprocess communication. 

Although little editing is now remote, economics may encourage changes. Terminals 
with limited local processing power (8-bit CPU, 4K bytes of memory) are now commercially 
available for as little as |600. Such a terminal could be dedicated to running x, and thereby 
present edit commands to the host processor while presenting a more pleasant interface 
to its user. To reduce communications over low-speed lines, such terminals might run an 
optimised x. For example, x now asks edit to search for keys; a terminal with local storage of 
the screen contents might first look there for the next occurrence of the key and so 
potentially save an edit request. 


CONCLUSIONS 

Many programs are written as stand-alone packages even when they might have been 
implemented as front ends to similar, though somewhat deficient, existing programs. The 
computational saving does not always justify the extra development effort. As hardware 
costs fill and programming costs rise, computational savings become less critical, an 
front ends become more attractive. Designers of operating systems can help by simplifying 
user multiprogramming. 

Front ends reduce the volume of code and so reduce portability problems. They also 
offer alternatives on the continuum between full-bootstrap portability (where little target 
machine software is used) and half-bootstrap portability (where much target machine 
software is used). For example, x could be distributed without edit (requiring an existing 
line editor but little installation effort) or with edit (requiring no fine editor but more 

installation effort). . , , . 

The success of the front-end screen editor recommends other applications ot tins 
strategy. For exam ple, the awkward interface presented by a dynamic debugger 10 mig 
be buffered through a screen handler that displays and allows editing of a user-specified 
set of machine variables. Or an editor might be used as a front end to a document formatter 
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to allow editing of the formatted result instead of the intermediate file of text and formats 
commands as is now common. Some such stand-alone systems "223 

installations. They are more easily written, maintained and transported L front Jndl! 
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APPENDIX: S COMMANDS 

This table outlines the s commands. All commands are initiated by a «intrl» character 
•rt? * p™«*we character r.pl«*. *, damtt, „ £ S. 

character typed and advances the cursor to the next character position. Typing the ASCII 

“%tr r tor £Xr ra ,he *— - £ «• -2sr 2^5 

printable replace character at cursor. 

cursor move move cursor without changing file or screen. 

± pages move forward or backward one screen full. 

± lines move forward or backward one line. 

± search move forward or backward until a key is found, 
delete delete one line ; copy to special file 

insert insert one blank line, 

pick copy one line to special file. 

P ut insert special file, 

set file edit new file, 

exit stop editing. 


All co mm ands accept an optional argument: 

PffWW . 0 . . 


8tring KKea) 0 ^ f °° ** PUt “ ^ * fter ** CurBOr “ fiJeand on the 

number (e.g. escape 2 + pages moves forward 2 screen fulls) 
cursor move (e.g. escape movement delete deletes all characters and lines between 
the initial and final cursor positions). 
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